What kind of change does this PR introduce? (check at least one)

• Bugfix

Does this PR introduce a breaking change? (check one)

• Yes
• No

Other information:

Fix bugs spotted in vuejs/vue-test-utils#317 (comment).

Some type theory shenanigans below:

This pull request allows assigning ComponentOption of a Vue subclass to Component. The problem is that we used to mark default vm type as Vue in Component. However, since ComponentOption is contravariant against vm type V. The default bound should not be the upper bound Vue, but the lower bound never.

For a more concrete example, consider this usage:

interface MyComponent extends Vue {
   num: number;
 }
 
const option: ComponentOptions<MyComponent> = {
  // a lifetime method
  created(this: MyComponent) { return this.num.toFixed() }
}

Then, assigning option to ComponentOption<Vue>, we could in theory do unsafe operation:

const anotherOption: ComponentOptions<Vue> = option

anotherOption.created.call(new Vue) // error! no property num on Vue!

Though it is not how we really use Vue, type checker cannot know this. To workaround, we can mark anotherOption to have vm type as never. never is the bottom type of any type, so ComponentOption<never>'s create method can accept nothing, and thusly any create method from subclass can satisfy accepting nothing semantic. In practical words, this means we promise that we never use created like the way above.